Skip to main content

Vibe UI

本版块介绍如何使用 AI 做出 有高级感的 UI，而不是满满的人机味。

网友案例：如何不写一行代码开发好：

首先是工具层面

1. Antigravity

这是整个过程中的主力，所有的指令-编码工作都在这里进行。里面可以选择使用Gemini和Claude模型。

2. 网页版Gemini

前期出方案的时候，我一般是先和网页里的AI聊，让它帮我出指令，我再将指令复制给Antigravity。但到后期的时候，因为项目越来越大，Antigravity对于业务的理解要明显高于网页AI，于是网页Gemini起到的就是辅助（当我质疑Antigravity方案时会问它）。

3. Aura

这个工具主要用来生产初版的视觉，它是专门针对静态页面的生成做了优化，所以是没有功能的，只有静态的html。后期有补充页面的时候，我还是用它生成。然后让Antigravity读取这个html，要求它完整移植视觉效果。

4. Poketbase

这个用来做后台，材料的上传、用户记录等等，Poketbase也是一个成熟的PaaS服务，在国外独立开发里很流行，在官网上注册好后把相关的密钥按照要求发给Antigravity，打通这个的过程，Gemini可以说是手拿把掐。

5. RevenueCat

这个用来接通苹果商店支付，也是一个非常成熟和流行的集成服务，同样来自国外但国内也能用，目前没有好的国产平替，Gemini对它的整个流程也是相当熟悉，只用了一次对话就接入完成。当然后期在状态同步等等问题上还是要花时间调试。

6. 阿里云大模型Qwen

这个主要用来实现app里的一个功能：上传音视频文件 - 识别出文本和翻译 - 生成带时间戳的材料。

7. 阿里云轻量化服务器

为了国内的访问速度以及国内上架，必须有国内的服务器。轻量化服务器的套餐从成本和性能都是独立开发者首选，但是这个服务器有一个控制面板叫宝塔，这个是个大坑，宝塔是一个三方公司，要实现app与后台的链接，必须在这个控制面板上进行编码，Gemini在这里花了无数的时间试错，下次有选择真的不想用宝塔🤦

8. Xcode

这个就重要起到一个把Antigravity的编码同步过来显示在iPhone上的作用。然后整个上架过程的操作也在这里进行。

1) Antigravity（主驾驶舱：持续上下文 + 直接改代码）​

你这张图里把它定位得很准：“主力、所有指令-编码都在这里”。它承担的其实是：

  • 代码生成/修改：按你的需求改前端、改业务逻辑、接 API、修 bug。
  • 项目级上下文管理：项目越大越需要“记住你到底要做什么、哪些改过、哪些不能动”，这也是你说后期它比网页版 Gemini 更懂你业务的原因。
  • 多模型切换：在同一个“工程上下文”里切 Claude / Gemini，让模型为同一份代码服务（而不是在网页聊天里丢上下文）。

公开信息里，Google Labs 的 Antigravity 被描述为面向开发者的实验性编码/代理体验（偏“代理式开发工作流”）。(pocketbase.io)

2) 网页版 Gemini（副驾驶：方案与指令工厂）​

它的价值不是“写最终代码”，而是：

  • 前期：把模糊需求→可执行指令（功能拆解、页面结构、接口草案、边界条件、验收标准）。
  • 后期：当“反对者/第二意见”（你说的“我质疑 Antigravity 方案时会问它”非常典型：用来做 sanity check、补盲点、找替代实现）。

3) Aura（视觉打样机：一次性产出“静态高质感 HTML”）​

你图里写得很清楚：它擅长“静态页面生成优化”。在工作流里它是：

  • 把 UI 质感快速打出来：字体、间距、层级、hover、动效节奏等（解决你吐槽的“AI塑料感”）。
  • 交付物是“可读取的 HTML/CSS”：后续让 Antigravity “照着抄”到真实项目（React/Next/原生 iOS WebView/Flutter 等都行）。

核心技巧就是你说的：Aura 负责“长相”，Antigravity 负责“活起来 + 融入业务”。

4) PocketBase（后端底座：账号/数据/文件）​

PocketBase 更接近“轻量 BaaS/自建后端”，典型用法：

  • 用户系统：注册/登录/鉴权（token）。
  • 数据表：用户记录、学习记录、配置等。
  • 文件上传：你说的“材料上传”。
  • 对 App 提供 API：前端只管调用。

它常被定位为“单可执行文件/轻量后端方案，适合独立开发快速起一个后台”。

5) RevenueCat（变现与订阅中台：对接 App Store 支付 + 状态同步）​

你图里的痛点也很真实：接入快，状态同步/订阅生命周期细节要慢慢磨。RevenueCat 在链路里负责：

  • 封装 StoreKit / Google Play Billing 的复杂度：你不用自己处理一堆边界。
  • 订阅状态统一：谁在试用、谁续费、谁取消、权益何时到期。
  • 服务端校验与事件：降低“客户端伪造付费”的风险，事件回调也更清晰。

RevenueCat 官方也明确把自己定位为“in-app purchases/subscriptions 的 SDK + 后端基础设施 + 数据归一化”。(revenuecat.com)

6) 阿里云大模型 Qwen（单点能力模块：音视频→转写/翻译/时间戳）​

在你的 App 里它是一个**“功能型 AI 服务”**，链路是： 上传音视频 → ASR 转写 → 翻译 → 输出带时间戳的结构化结果（字幕/学习材料/卡片素材）。

7) 阿里云轻量服务器 + 宝塔（国内部署与加速层）​

你这段话的本质是：

  • 为什么要国内服务器：国内访问速度、合规/上架/域名解析/服务稳定性等现实约束。
  • 轻量服务器：性价比高，适合独立开发者。
  • 宝塔坑点：控制面板把“服务器=可视化配置”包装得很舒服，但一旦涉及自定义部署、反代、证书、进程守护、权限与目录结构，就容易和 AI 的“想当然脚本”打架——于是出现你说的“无数时间试错”。

8) Xcode（上架与真机验证枢纽）​

它承担两件事：

  • 把代码跑到 iPhone 上验证（真机调试、签名、性能、权限弹窗、IAP 测试）。
  • 上架全流程（证书/签名、Archive、TestFlight、App Store Connect 提交与审核相关配置）。

3) 这个 workflow 怎么跑通（你这套“vibe coding 上架链路”的关键结构）​

把你图里的流程抽象成一条“高成功率流水线”：

  1. 需求与方案（网页版 Gemini）
    • 先把功能拆成可验证的 checklist
    • 产出“给 Antigravity 的指令格式”：要改哪些文件/模块、验收标准、禁止改动项
  2. 视觉打样（Aura）
    • 生成高质感静态 HTML（尤其是：间距、字体层级、hover、scroll 动效、micro-interactions）
    • 这一步的目标不是“能运行”，而是把审美基线拉上去
  3. 工程实现（Antigravity）
    • 读取 Aura 的 HTML → 移植到真实工程组件体系（React 组件 / Tailwind / 设计 token）
    • 接入业务逻辑与状态管理
    • 形成“项目级记忆”：哪些地方是设计基线、哪些是业务硬约束
  4. 后台能力（PocketBase）
    • 建表（用户/记录/素材/日志）
    • 鉴权与权限
    • 文件上传与访问策略
    • 把 API 契约固定下来（后面 UI 才不会反复返工）
  5. 变现能力（RevenueCat）
    • 快速接通 IAP/订阅
    • 难点集中在：订阅状态同步、权益发放、恢复购买、跨设备一致性（这就是你说后期要调试的部分）
  6. AI 功能模块（Qwen）
    • 把“音视频→材料”做成独立服务/接口
    • 输出结构化数据（带时间戳）回写 PocketBase（或你自己的后端）
  7. 国内部署（阿里云轻量 + 宝塔/替代部署方案）
    • 部署 PocketBase/自建 API/静态资源
    • 做反代、HTTPS、域名、CDN（如有）
    • 目标：国内可用、稳定、可观测（日志/告警）
  8. 真机与上架（Xcode）
    • 真机调试：权限、网络、IAP 沙盒、崩溃
    • Archive → TestFlight → 提交审核